As various forms of distributed computing, such as cloud computing, have come to dominate the computing landscape, security has become a bottleneck issue that currently prevents the complete migration of various capabilities and systems associated with sensitive data, such as financial data, to cloud-based infrastructures, and/or other distributive computing models. This is because any vulnerability in any of the often numerous assets provided and/or utilized in a cloud-based infrastructure, such as operating systems, virtual machine and server instances, processing power, hardware, storage, applications, connectivity, etc., represents a potential vulnerability. Consequently, the number, and variety, of potential vulnerabilities can be overwhelming and many currently available vulnerability management approaches lack the ability to track and control these potentially numerous vulnerabilities in any reasonably comprehensive or tailored manner.
As noted above, the situation is particularly problematic in cases where sensitive data, such as financial data, is being provided to, processed by, utilized by, and/or distributed by, the various assets within the cloud. This is largely because exploitation of certain vulnerabilities in some asset can yield devastating results to the owners of the data, even if the breach is an isolated occurrence and is of limited duration. That is to say, with sensitive data, developing or deploying a remedy for a vulnerability after that vulnerability has been exploited is no solution at all because irreparable damage may have already been done.
Consequently, the historic, and largely current, approaches to vulnerability management that typically involve addressing vulnerabilities on an ad-hoc basis as they arise, or in a simplistic, uncoordinated, static, and largely manual, manner are no longer acceptable. Indeed, in order for applications and systems that process sensitive data to fully migrate to a cloud-based infrastructure, security issues and vulnerabilities must be addressed in a proactive, anticipatory, and comprehensive manner, well before any potential attack can possibly occur, e.g. before deployment and publishing. However, currently, this type of comprehensive approach to vulnerability management is largely unavailable, or is prohibitively resource intensive, often requiring significant amounts of dedicated hardware, software, and human administrators that are often used in a largely reactive and ad-hoc manner.
As a specific example, application development within a cloud infrastructure provides numerous opportunities for the introduction of vulnerabilities into the application and/or infrastructure. These vulnerabilities typically take the form of weaknesses within the assets used at various stages of the application development process that make the application development process, the application, and/or infrastructure, susceptible to various attacks and/or result in violations of defined security policies or procedures. The types of vulnerabilities of concern varies widely from asset-to asset, application-to-application, development platform-to-development platform, and deployment platform-to-deployment platform. For instance, as an illustrative example, vulnerabilities can take the form of a software flaw, or software created in a known vulnerable version of a language. As another example, a vulnerability can be a lack of proper authentication, an unacceptable level of access, or other insufficient security measures, required to meet the security policies and/or parameters associated with the application, the application development platform, and/or the application deployment platform.
In addition, vulnerabilities, and application characteristics, of particular interest, are not necessarily static, and are therefore subject to change based on new data from the field, the type of application being developed, the version of the application being developed, changes in the application developer platform, and/or changes in the application deployment platform. Consequently, even in the case where “all” vulnerabilities associated with an application development process are believed to be known, the list of vulnerabilities is dynamic and highly dependent on other, often currently unknown, parameters and/or characteristics.
In addition, if certain vulnerabilities are not identified at specific critical stages in the application/asset development process, e.g., at a critical stage of the application development pipeline, these vulnerabilities can propagate, and become so embedded in the application and infrastructure, that a single vulnerability in a single asset used in the application development process can result in a chain of vulnerabilities that extend beyond the application and can result in significant portions of infrastructure associated with the application being vulnerable to attack. Once this happens, the process for removing the vulnerability, and/or chain of resulting vulnerabilities, can become more difficult by orders of magnitude and can eventually consume unacceptable amounts of time and energy to correct.
Despite the situation described above, vulnerability management currently consists largely of the uncoordinated deployment/application of single vulnerability scans, often preformed after the vulnerability has been provided the opportunity to propagate through an asset and the infrastructure to become a chained vulnerability. Therefore, currently, many vulnerability management issues are ignored, or vulnerability remediation is performed in a reactive, piecemeal and incomplete manner. As a result, current levels of security are unacceptable for some systems and an unacceptable amount of resources are currently devoted to removing chained vulnerabilities that could have been removed with much less effort had they been identified earlier in the application development pipeline.